That is awesome - I'm on Octopus Agile in the UK and it has negative rates from time to time. I hadn't considered whether this was supported or not. Definitely of interest when charging my EV.

I think we have to solve it with a bit more complex way. Issue is that at least in our region when you buy electricity total price will be nordpool + tariff + VAT (export), but when you sell electricity its nordpoool wo. VAT (import).

Now at the moment only one price is given to the integration which in my case is total electricity price.

Cost can be negative in two cases:

1. Because of electricity price is negative. In this case yes, when total electricity price (nordpool + tariffs + vat) is negative, this device is "earning money" and it's proper to use the total electricity price
2. When the consumption is negative. In this case consumption should be multiplied with the export price (nordpool wo. VAT) to get the right "earning". For example using grid sensor here.

So to do this right and support all scenarios this should be done:

1. User must insert both import and export price entities in configuration screen. If the import/export price is same, then user can fill the same enity in both fields
2. There should be option in configuration screen for user to select if it would be Net consumption like in HA native Utility meter. (Enable if the source is a net meter, meaning it can both increase and decrease)
3. Logic has to be rewritten to take account the two scenarios of negative price and negative consumption, so that integration calculates with the right electricity price (import or export)

It looks a bit overwhelming for me, so any contributions are welcome.

This makes sense if the integration is being used to measure the total energy spend for a household, but not my use case where I am only using it to measure the cost of running specific devices such as my EV. In those cases is the export price relevant?

I'm quite happy using HA's built in Energy functions for calculating my overall spend, and just use this integration to see how much certain appliances are costing to run on a highly variable tariff that can go negative. I don't export energy so I can't say whether HA is good at handling that.

I understand the complexity and as such I would suggest to keep the component as simple as possible, leaving out too many scenarios.

For example on your second example:
"When the consumption is negative. In this case consumption should be multiplied with the export price (nordpool wo. VAT) to get the right "earning". For example using grid sensor here."

That is indeed true for a grid sensor but not when measuring an home-battery sensor. When the consumption of a device is negative I may not be "earning", but "saving" costs in which the correct costs savings are calculated using the import price (northpool with taxes). On the same token the energy cost of a device might be the "missed earnings" when the source of the electricity are solarpanels.

We could indeed support two price sensors, one for positve energy usage and one for negative. However following the above rationale I recommend to have the price sensor itself to contain this logic, and determine the current electricity price based on if there is a net delivery, or net energy consumption to the grid.

{% if states('sensor.net_energy_usage') | float >= 0 %}
{{ states('sensor.nordpool_with_taxes') }}
{% else %}
{{ states('sensor.nordpool_without_taxes') }}
{% endif %}

Using the above as price sensor would give a more exact costs indication. Afterall when your are net-delivering to the grid the energy price is what you "miss out" when not exporting to the grid

ps. When the market price is negative, and you are net delivering, its costing you money. As such a device consuming energy is saving you money. With the above proposed price sensor this is correctly taken into account. When delivering energy, the price sensor is set to nordpool without taxes, which is then negative. The energy used with the negative nordpool price is then correctly reducing your total cost

@Pluimvee, thank you very much for contributing. I’ve been so busy that I didn’t have time to maintain the integration.

I think your approach looks good, so let’s proceed with it. Maybe in the future, we can think about adding import and export prices.

Since I’m still quite busy, I’ve added access to the repository for you, so you can make the commit. It looks like there’s a conflict because of another pull request.

Also, I would be happy if you could co-manage this integration. There are some other issues that need attention as well.

EDIT: Did some more fixes, so @Pluimvee please check your pull request.